home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Q FWDrCmd & fSelection.3 < prev    next >
Encoding:
Internet Message Format  |  1996-07-16  |  1.6 KB  |  [TEXT/ttxt]

  1. Subject:     Re: Q: FWDrCmd & fSelection
  2. Sent:        7/15/96 4:45 PM
  3. Received:    7/15/96 4:21 PM
  4. From:        Bernie Wieser, octavian@agt.net
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Mark L.
  9. >I see two solutions: build a non-debug version of your part, or change the
  10. >source code (it doesn't bite). You've already determined that the assert
  11. >does not indicate a serious problem (since you don't crash if you
  12. >continue). So what's the problem here?
  13.  
  14. You and Damon have very valid points, and I did comment it out
  15. for debug builds, but changing stuff in the framework typically
  16. is not overridable is something that Henri L. warned against.
  17.  
  18. My concern was that having a no selection would cause other
  19. problems; why was this assert there if this is not an error?
  20. Aren't such assertions there if i.e. fSelection was actually used?
  21. It's great to know if I am about to do a Nil violation...
  22.  
  23. If there are no serious repercussions, then doing it either way is fine.
  24. Thanks for the info.
  25.  
  26. >>FWDrCmd.cpp@430 - fSelect != Null <-- why you won't see us on DR6.
  27. >
  28. >Oh please.
  29. Yeah, a bit much, but it got a response.  There are real reasons why we
  30. don't have a DR6 ODF part.  Our browser currently uses ODF to implement a
  31. twist-down list and an in-depth list.  As you can guess, watching them
  32. redraw won't do much for end users.  Among many outstanding issues, we need
  33. to do Mac. specific scrolling for lists and hiliting.  It would be really
  34. nice if ODF could help here, but Henri already said these are futures.
  35.  
  36.  
  37.